Caused by: org.exoplatform.services.jcr.impl.storage.value.ValueStorageNotFoundException: No value storage found with id portal-system
This is critical, you need to backup all your databases.
Indexes can be rebuilt and we recommend to do so, it may however take a long time depending on the size of the portal. We recommend to keep a copy of the indexes as well.
In EPP 5, the JNDI pattern for datasource names had the portal container name as suffix only when there were two portal containers or more. Adding a second portal container was troublesome as it meant that a user would have to add a portal container suffix to the existing default portal container.
Starting with EPP 6, the portal container name is always suffixed to the JNDI name of the datasource.
Here are the default values for EPP6:
java:/jdbcidm_portal for the user storage
java:/jdbcjcr_portal for the JCR storage
Make sure to use those correct patterns when defining your datasources in standalone/configuration/standalone.xml.
There is no data migration per-se, but a couple of default options have changed and needs to be changed back in order to get EPP to fully work with data stored with previous portals.
In previous version of JPP, binary files and large text files were stored in the filesystem. In most common scenarios, only gadget images would be stored that way and in most cases a better default configuration is to store everything in database since it reduces shared file system overhead and backups. In JPP 6.0, all the JCR data is stored in the database as default. Existing customers currently have binaries stored in file-system and metadata in database, the portal needs to be configured so that data is picked from the right source.
Failing to do this change will result with ERRORs such as:
Caused by: org.exoplatform.services.jcr.impl.storage.value.ValueStorageNotFoundException: No value storage found with id portal-system
To change back the behavior, in JBOSS_HOME/standalone/configuration/gatein/configuration.properties for all nodes do the following changes:
gatein.jcr.storage.enabled=true gatein.jcr.storage.data.dir=<<use your former value, pointing to the shared 'values' directory>>
Make sure there is no other conflicting definition of those values in the file.
You will also need to rename all directories since they will all include the name of the portal container:
values/pc -> values/pc_portal values/system -> values/system_portal values/wsrp -> values/wsrp_portal values/portal-system -> values/portal-system_portal values/portal-work -> values/portal-work_portal
By default, JPP 6 allows to store data for each JCR workspace in their own tables, it's not possible to split current data into individual tables and the portal needs to be configured back to the former default to properly work.
To do so, edit: JBOSS_HOME/standalone/configuration/gatein/configuration.properties
And modify:
gatein.jcr.db-structure-type=isolated
To become:
gatein.jcr.db-structure-type=single
Previous versions of JPP required a shared file system to be setup in order to have a single copy of the JCR indexes across all nodes of a clustered environment. In EPP 5.2 we introduced a way to have each nodes of a cluster keep a local copy of the indexes, it is now the default option.
To keep the previous behavior you will need to uncomment in JBOSS_HOME/standalone/configuration/gatein/configuration.properties for all nodes:
# JCR # All gatein nodes have to point to the same shared filesystem directory gatein.clustered.data.dir=<<use your former value, pointing to the shared 'lucene' directory>> gatein.jcr.index.changefilterclass=org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter
If you prefer to switch to the new default behavior you would need to make sure:
gatein.clustered.data.dir does not point to a shared directory, by default it points to JBOSS_HOME/standalone/data/gatein/jcr/lucene for each node.
And on the next start, JPP will rebuild the index and share on all nodes.
The Web Services stack used between EAP 5 and EAP 6 has changed and the implementation is now based on Apache CXF.
The configuration to setup WS-Security has changed and should be redone according to the reference guide https://docs.jboss.org/author/display/GTNPORTAL35/Securing+WSRP
Covered in the Migration Guide here: [https://docs.jboss.org/author/display/EPP60/Migrate+Java+Server+Faces+2+%28JSF2%29+Portlets|../../../../../../../../../../display/EPP60/Migrate+Java+Server+Faces+2+%28JSF2%29+Portlets||||||||||||\||]
JavaEE 6 is more strict when it comes to EAR packaging. Previous examples of portal containers and portal extensions listed utility jars in META-INF/application.xml and those will not be available without setting up the other modules Classpath depending on it.
To make the portal containers and extension work, utility JARs should be moved to a 'lib' directory (or any other packaging respecting Java EE 6 classloading expectations).
A typical package would look like:
|-- my-company-extension.ear | |-- my.company.extension.war | |-- lib | | |-- my.company.extension.config.jar | | `-- my.company.extension.lib.jar | `-- META-INF | |-- application.xml | |-- MANIFEST.MF
In EPP5, URL handling was improved and the public and private qualifiers in the url no longer specified the authenticated or unauthenticated section of the portal. In order to provide backwards compatibility with older urls, accessing something like /portal/public/classic would redirect the user to /portal/classic. Accessing something like /portal/private/classic would redirect the user to /portal/classic and optionally redirect first to the login page if the user was currently unauthenticated.
In EPP6 the user will only be redirected to the login page if the redirect is to a page which requires authentication. This means that accessing /portal/private/classic will redirect the user to /portal/classic without first redirecting to the login page (since /portal/classic by default does not require authentication).
The old behaviour can be added back into EPP6 by modifying the portal's web.xml to include portal/private/* as a url-pattern in the security-constraint section. Being able to add back in this ability will be removed in future versions.
In JPP6 there are 2 new options in Picketlink IDM configuration file JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/idm-configuration.xml. Those 2 options are new in JPP6 and they affect especially customers with LDAP configured as Default store. Details about options:
ignoreMappedMembershipTypeGroupList - This option should contain list of roles, which are mapped to Picketlink IDM as simple relationships and not as roles. It affects especially customers, who are using LDAP as Default store, because they usually need to mention all groups, which are mapped to LDAP. So for example if customer has groups /platform/* and /organization/* mapped to LDAP groups, the content of the option should look like this:
<field name="ignoreMappedMembershipTypeGroupList">
<collection type="java.util.ArrayList" item-type="java.lang.String">
<value>
<string>/platform/*</string>
</value>
<value>
<string>/organization/*</string>
</value>
</collection>
</field>
For customers who are using LDAP as Read only store or who are not using
LDAP (DB only setup), the list should be empty, so the option should be like this (This
is also default value):
<field name="ignoreMappedMembershipTypeGroupList"> <collection type="java.util.ArrayList" item-type="java.lang.String"> </collection> </field>
skipPaginationInMembershipQuery - This is boolean option with
default value true, which means that pagination of memberships in JPP
UI is disabled (skipped) by default. You can switch to value false if
you have DB only setup. Switching to false will enable pagination of
memberships in JPP UI and so it increase performance. But note that for
DB+LDAP you shouldn't switch to false because pagination won't work
correctly for DB+LDAP setup.